軟體開發有個情境或許大家都不陌生：

團隊可能接手外包所開發的程式，或是接手團隊其他成員所寫的程式繼續開發，
但碰到了一些難以繼續開發或維護的問題，這些問題造成的原因可能很複雜，
成因可能都與你無關，但你無法改變過去，卻也害怕改變現狀。

例如：
專案沒有留下文件，且當初時並沒有訂定良好的規範，程式碼的實作雜亂無章，常常有無法預知的 bug。
專案沒有寫測試，當初交付時也沒有完善的驗收流程，接手時發現專案與預期落差太多。

重點是，目前接手的這個專案，已經上線了！

對於持續開發或維護一個已上線產品的團隊來說，常常是進退兩難，只能一直長痛下去。

因為沒有測試，沒有文件，誰也不敢亂動，索性就不要隨便動手好了，反正線上的東西還能動就好，深怕一動了，就下不了班了。但是若要加新功能又只能在目前的債上繼續加債下去，每天還有找不完的 bug 要修。

然而放任這個痛楚一直持續下去的話，其實也影響了團隊的效率及產出價值。

有時候在負面的情緒之上，剛接手的人很容易冒出一個念頭：重寫啦重寫啦，砍掉重練啦。
但是重寫就能解決問題嗎？

請再回想一下，我們必須要解決的是「現實問題」，但我們必須考量「現有資源」以及「時效」。

這個時候需要好好思考一下這三個面向，才能好好做決策：
（嗚嗚，這裡其實要好好說明一下，但目前來不及）

• 情境
• 目的
• 評估情勢與利弊

每個團隊面對的情境都不一樣，沒有一套能完全複製來照著做的決策與流程。
因此，身為團隊的一員又或者是管理者，如何評估利弊及情勢，又是一門學問了。
明天再來討論一下團隊及管理者的關鍵要素。

啊啊啊啊啊啊啊，我明天開始一定要好好寫文章
每天都壓線好哭哭

我這麼廢，菜逼八的，哪時候才能當快樂的 IT 管理人，哭哭